Conversation
Benchmark resultsMetrics with a significant change:
Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every circuit run across all benchmarks.
Tree insertion statsThe duration to insert a fixed batch of leaves into each tree type.
MiscellaneousTransaction sizes based on how many contract classes are registered in the tx.
Transaction size based on fee payment method
Transaction processing duration by data writes.
|
Docs PreviewHey there! 👋 You can check your preview at https://661e2d4ecf80ac0606c61dbc--aztec-docs-dev.netlify.app |
sirasistant
force-pushed
the
arv/trap_with_data
branch
from
3ebf717 to
f562989
Compare
| rhs, | ||
| } => { | ||
| assert!(is_integral_bit_size(*bit_size), "BinaryIntOp bit size should be integral: {:?}", brillig_instr); | ||
| assert!( |
There was a problem hiding this comment.
I think we weren't running cargo fmt on this file :)
There was a problem hiding this comment.
ouch, I was just working on it but I guess if I run cargo ftm as well I'll be ok :D
| rhs, | ||
| } => { | ||
| assert!(is_integral_bit_size(*bit_size), "BinaryIntOp bit size should be integral: {:?}", brillig_instr); | ||
| assert!( |
There was a problem hiding this comment.
ouch, I was just working on it but I guess if I run cargo ftm as well I'll be ok :D
| BrilligOpcode::Trap { /*return_data_offset, return_data_size*/ } => { | ||
| // TODO(https://github.com/noir-lang/noir/issues/3113): Trap should support return data | ||
| BrilligOpcode::Trap { | ||
| revert_data_offset, |
There was a problem hiding this comment.
Will this be direct or indirect? I.e., do I have to read from [revert_data_offset, revert_data_offset+size]?
There was a problem hiding this comment.
ouch, I was just working on it but I guess if I run cargo ftm as well I'll be ok :D
I think rust-analyzer ships with vscode formatting :D
vezenovm
left a comment
vezenovm
left a comment
There was a problem hiding this comment.
Some minor nits but looks good
We could do this if we support returning a dynamic string in Brillig. I originally held off on adding it for dynamic assertions as to stay in line with ACIR. We have broken away with features in Brillig and ACIR (e.g. break and continue) so I think it would be fine to add this feature. |
Co-authored-by: Maxim Vezenov <mvezenov@gmail.com>
Co-authored-by: Maxim Vezenov <mvezenov@gmail.com>
I'm going to think more on this line because this seems interesting! |
The reason we didn't resolve format strings in ACIR is because a fmt string resolution would require slices. But perhaps we could avoid a divergence with a better Display interface. We have an issue here for improving how string formatting is handled (noir-lang/noir#4238). We also have considered moving constraint errors to be more generalized and as part of the ABI (noir-lang/noir#4239). |
4 participants
This PR adds revert data for user-defined messages in the TRAP opcode. Not all messages are returned as revert data, since compiler intrinsic messages are spammed all over SSA and codegening revert data for all those makes brillig function size blow up and impacts performance in a hard way due to deserializing load.
This is currently only for static assert messages, since dynamic ones are implemented as an oracle and probably need a rework to be able to return them as revert data.